1. Technical Field
This invention relates to a communications transport protocol for transmitting data in a communications network and in particular to a method, data processing system and software application program for transmitting, receiving or transmitting and receiving data over a multicast enabled communications network.
2. Related Art
Traditional methods of information retrieval include the client/server request-response transaction model where a client sends a request to a server and waits for a reply. This model prescribes that clients should initiate requests and that servers should listen for requests and respond to them. This approach has the disadvantage that if an item of information requested by a client changes after the server has replied the change is only discovered if the client issues another request. The server is stateless, that is to say, it does not store information relating to the client, for example the information that was last sent to a client.
One approach taken to address the constraints of the client/server model for data transfer is the so called “push” server model. The “push” approach, found in services such as Microsoft's Active Channel for example, is not really a push model at all since a server by definition cannot push to a client. Instead the client is arranged automatically to poll the server for new data at pre-defined intervals using conventional client/server interactions and to pull down new data according to pre-determined selection criteria. The main disadvantage of the “push” model is that if the number of clients is large and the information changes frequently the server can be overwhelmed since a copy of the updated information must be transmitted separately to each client that requests it. The problem of replicating data transmissions is also relevant to the so called “stateful” server model where clients register with the server and are notified by the server when relevant information is updated.
The above approaches are based on unicast communications, typically using Transmission Control Protocol (TCP) across Internet Protocol (IP) networks to guarantee delivery.
Multicast transmissions are becoming increasingly common on the Internet. In contrast to standard Internet Protocol (IP) point to point transmissions (unicast), IP multicast allows the simultaneous transmission of information to a group of recipients from a single source. Routing support for IP multicast transmissions is provided by multicast enabled regular routers, or by general purpose computers with multicast routing-enabled that are linked to form the MBone (IP Multicast Backbone) which is a virtual network layered on top of the Internet.
Multicast provides another approach to data transfer. In this approach a multicast server transmits data over one or more multicast channels which one or more client receivers join or subscribe to. In this model the server only sends out one copy of the data irrespective of the number of client recipients listening to the appropriate multicast channel or channels. In IP multicast the server does not even need to know who the recipients are or the number of recipients in a particular multicast group.
IP multicast allows real-time communications over wide area IP networks and typical transmissions include video and audio conferencing, live multimedia training, university lectures, and transmission of live television and radio programmes, for example. IP multicast also allows more persistent data to be transmitted, including for instance media session descriptions comprising session oriented and user oriented data.
A multicast media session usually consists of one or more individual media streams typically carrying video, audio, whiteboard or raw data. Some sessions are persistent, but the majority exist for a specific period of time, although need not be continuous. Multicast based transmissions differ from unicast IP transmissions in that any user knowing about the transmission can join the session (unless the transmission is encrypted) and to receive a transmission, a user only needs to know the appropriate transmission group address and timing information for the session.
Prior to a multicast transmission an appropriate announcement containing a session description is made, usually at a well known IP multi-cast group address. Standard session descriptions are generated using Session Description Protocol (SDP), as defined in the Internet Engineering Task Force's draft RFC 2327. SDP is a simple ASCII text based protocol that is used to describe real time multimedia sessions and their related scheduling information. SDP messages are wrapped in a carrier protocol, known as a Session Announcement Protocol (SAP), which, in addition to containing the necessary IP addressing and routing information for transmission across the Internet or MBone, allows the SDP message to be encrypted, signed or compressed. An announcement can then be sent at regular intervals to the announcement group address which comprises a single IP multicast channel.
SAP is an IETF experimental standard and is currently used by the academic and research community to announce media session descriptions which are usually constructed in accordance with SDP. Despite the widespread use of SAP there are a number of drawbacks with the protocol. Firstly, a single well known IP multicast group address, otherwise known as a multicast channel, is assigned for SAP announcements. Thus, the announcement rate for SAP is relatively low with typically several minutes elapsing between repeated announcements. Moreover, although SAP will scale to any number of receivers it will not scale to more than say a few thousand announcements even with local receiver or proxy caching. Thus, while the use of a single well know multicast channel is well suited for the current small IP multicast user community it is a highly inappropriate model for use by the broader Internet user community. The advantage of using a single well known channel that every user can listen to is far outweighed by the bandwidth limitations of a single channel.
Hierarchical SAP [‘Describing session directories in SDP’ an IETF Internet Draft by Ross Finlayson] alleviates this problem, by simply allowing any of the media session descriptions on the single well-known channel to describe a secondary channel for announcing media descriptions. This can continue by creating further tertiary channels and announcing them on the secondary channels and so on. As long as the grouping of announcements on each sub-channel matches the interest of the listeners, this reduces waste of receiver bandwidth. However, because receivers interests never coincide to any great degree, considerable unnecessary traffic still has to be received by any receiver, and therefore has to be transported across intervening networks unnecessarily. Further, senders can only limit the bandwidth required to listen to any one channel. If a receiver has to listen to a number of channels to monitor all its interests, the bandwidth received may well be excessive. Also, although splitting up the channels improves the timeliness of announcement updates, they are still delayed by the need to allow other repeating announcements to intervene between any two announcements about the same item.
SAP announcements are restricted in size, typically to 576 bytes for global announcements or the size of one IP packet, to prevent network congestion and conform to the requirements of many IP hosts which have a maximum 512 byte payload. Further, SAP has been designed to support one instance of a very specific application, that is to say, a global directory for multimedia sessions. In this regard SAP assumes that the payload it carries is a session description, and in particular a session description constructed in accordance with SDP. Thus, data such as session id and timing information, which is useful for announcement deletion purposes, is hidden from the SAP header and is only available when the SDP payload is processed. Similarly, although the SAP header contains a “message id hash”, which can be used to distinguish announcements, it is impossible to determine whether the receipt of a new value in this field indicates that a new announcement is being made or an existing announcement is being updated, that is without first parsing the SDP payload to obtain the session id.